By David C. Moss
As we've discussed in previous articles, Process, Function, and Matrix modeling are techniques you can use to model the logical business needs of your organization. A logical model consists of all the things your organization does and the information needed to do them. A complete logical model is the most effective way to determine the areas in your organization that would benefit most from automation and is the precursor to solid physical database and application design.
In this article, we'll take a look at how to turn your Business Function model--including elements from the Process, Function, and Matrix models--into a physical description of the applications you want to create. These application definitions, which you'll further refine, will eventually become the basis for creating Forms, Reports, and Stored Procedures--ultimately generating actual working code.
In our May article, we discussed how to create and view various matrix models in the Matrix Diagrammer. We explained why it was important to examine each elementary function to ensure it has all the necessary information to do its job, including a complete CRUD (Create, Retrieve, Update, Delete) map.
Before your matrix work is complete, you'll need to check each elementary function for missing entities. You'll then need to run the Create Function Attribute Matrix utility, which is located on the Utilities pulldown menu in the Repository Object Navigator. This clever application takes the Function to Entity matrix information you've already entered, including the CRUD map, and expands it to include all attributes for each entity. You'll need to further refine this matrix because it will become the basis on which the Application Design Wizard will create detailed application definitions.
Before you begin translating your logical application model into a physical application model, you must verify the business need for each elementary function. One of the ways to verify the business need is to ask your users. However, this method doesn't produce any lasting documents. And lasting documents are crucial because people tend to forget what they agreed on.
We therefore recommend that you review, with your users, each elementary function, including its description, the entities it uses, and any triggers for the function. You can use Designer/2000's Function Definition in the Repository Object Navigator to produce the type of report you need. To reach it, drill down from Reports to Functions to Function Definition. In the Function Definition dialog box, set Elementary Function to True and Function to % so you'll get a report of all the elementary functions.
As we've discussed in previous articles, we recommend that you keep an open mind about possible physical outcomes during all of the Strategy and most of the Analysis stage of your project. You can accomplish this by modeling precisely what you discover in the organization you're studying--a process called divergence. However, as you move closer to the completion of the Analysis stage and have collected most of the detailed information that your application needs, we recommend that you turn your attention to convergence. This means examining your models to see if there are similar or repeating processes and functions that could be better handled by one application.
You should also make your applications as object-oriented as possible. Now is the time to begin identifying opportunities for creating reusable business functionality. These reusable pieces could become prime candidates for stored procedures in your physical application model. Using Structure Charts is a wonderful method for identifying potential reusable functionality. Chapter 14 of CASE*Method - Function and Process Modelling has an excellent discussion of this technique.
You'll need to do one very important task before you're ready to translate your logical application model into a physical one: Create a final document and sign off on the logical model. This simple--but often overlooked--step makes everyone accountable for their agreement on the scope of the application. Don't underestimate the importance of this task. Many software projects have fallen to ruin because this task alone was ignored.
As we've mentioned before, you develop the logical model and the scope of the application during the Strategy and Analysis stages. The Design stage is the appropriate time to do the logical-to-physical translation, after you've performed all quality checking and signed the application documents.
But beware: One of the classic problems that can throw a project off course occurs during the mapping of the relationship between the logical and physical definitions. Without automation, performing this mapping for hundreds of elementary functions is so cumbersome that many project managers simply trust that all functionality is appropriately mapped. This is like believing in the Easter Bunny. Fortunately, you can use the Application Design Wizard to do the mapping for you.
The Application Design Wizard automates much of the initial translation process from logical to physical application definitions, utilizing Function Definitions and the Function to Entity and Function to Attribute matrix. We'll refer to the Application Design Wizard dialog box, shown in Figure A, to show you how to get the most out of this process.
First, you need to choose the appropriate Generate Options setting. We used the default, Modules. Later, when we've defined all the modules, we can also generate menu definitions by selecting the Menus radio button. Selecting the Modules option enables the Module Options Language portion of the dialog box. You use the Screen list box to tell the Application Design Wizard if you want to create Oracle Forms, Visual Basic, or other screen definitions. The Report and Utility Language list boxes operate similarly. Remember, you're not locked into a language selection until you generate the module itself. Right now, we're going to generate only module definitions.
The Application Design Wizard uses your selection in the Frequency/Response Needed section of the Business Function Properties dialog box from the Function Hierarchy Diagrammer to determine whether the module will be a screen, report, or utility. Immediate implies that the user needs immediate feedback and, therefore, a screen or report. Overnight implies that the user would be satisfied with a report or utility. Utility is also the classification given to Stored Procedures. Be sure to indicate the response needed for each elementary function, or the Application Design Wizard will default to Screen for the module language.
The Merge Granularity section of the Application Design Wizard dialog box presents you with three choices you can use to guide the application in determining how to combine similar functions. Usually, you will have performed a thorough analysis of your functions and will have already uncovered similar ones. However, it's easy to miss similarities when you're dealing with numerous functions.
So, if you choose Identical Entities, any elementary functions that use the same entities will be merged into one module definition. If you select Identical Entities and Usages, the functions won't be merged into one module unless the entities and the Function/Entity CRUD are the same. If you select Identical Attributes, only those modules using the same attributes will be merged.
Finally, in the Common Parameters section, you'll need to select the position on the Function Hierarchy that the Application Design Wizard will start from. We suggest you select the highest position on the Function Hierarchy as a starting place, so the entire set of module definitions will be generated at one time.
When you're satisfied with all the settings, click the Generate button. A window will open with the message, Creating Candidate Modules from Function Definitions, Entity and Attribute Usages, Dataflow Definitions, and Business Unit Associations. You're on your way!
Well, we did it again: Most of this article discusses what you need to do before you execute a utility program in Designer/2000! In real-life CASE projects--at least the successful ones--you actually use CASE tools only after you spend time with your users gaining a complete understanding of the application. The human side is the most ignored, yet the most critical, element of software development.
Once you've reached an agreement with your users on the scope of the project and the budget, you must put into place a process known as Change Control. The Change Control process helps you track the scope of your project and ensure that any proposed changes to the application are carefully examined and weighed against budget and time constraints. And it helps ensure that the hard work you've invested in your logical models won't be wasted.
Now that we've crossed the river from logical to physical models,
we need to verify, clean up, and add detail to those physical
models to prepare for the creation of database objects and programs.
Therefore, we'll be exploring topics related to physical design,
including key definitions and table design tasks in the next several
articles. If you'd like to find out more about Oracle's approach
to application models, please read CASE*Method - Function and
Process Modelling by Richard Barker and Cliff Longman (Oracle/Addison-Wesley,
1992). We highly recommend Chapters 10 and 14, which cover logical
and physical system design.
David Moss is a managing consultant with TrueNorth Consulting, Inc. You can reach him by phone at (503) 220-1790 or by E-mail at truenrth@ix.netcom.com.
[Return to Index for Exploring Oracle Developer/2000 and Designer/2000 - July 1996]
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.
